The information presented here is placed in the public domain, and was written by Doug Burke. The notebook used to create this page is available, and questions can be asked using the GitHub issues page or via Twitter: https://twitter.com/doug_burke.

Haskell and Cosmology

... or at least, a little bit of each.

Although I mention a few bits and pieces below, I'm going to leave it to Ned Wright's Cosmology Tutorial to explain things properly. Ned's javascript Cosmology Calculator should also be preferred to any of the code presented here, as I am ignoring some things (e.g. the contribution of neutrinos).

This is not intended to be a Haskell tutorial, rather it is meant as an example showing that it is possible to use Haskell for Astronomy. Haskell is rather different to the computer languages commonly used in Astronomy, so I try and provide Python equivalents as I go along. One thing I am not going to do is try and convince you that Haskell is the one true language for Astronomy, since it isn't. I also don't think that many of the selling points of functional programming, or using a static typing system with type inference, can easily be shown in an IHaskell notebook.

If you are interested in learning more about Haskell, then I suggest you look at one of the several guides to Haskell out there on the internet, such as Chris Allen's Learn Haskell, How to Learn Haskell, and Stephen Diehl's "What I wish I knew when learning Haskell". The newly-renovated Haskell home page is also a useful resource.

Last time the notebook was run

What is the aim of this page?

I was recently re-reading the paper "Experience Report: Type-checking Polymorphic Units for Astrophysics Research in Haskell" by Takayuki Muranushi and Richard A. Eisenberg (Haskell Symposium 2014, Gothenburg, Sweden) and wanted to try out the units package. I have some (private) code that calculates cosmological quantities (distance, time, volume) that uses a different approach for handling units in Haskell (via the dimensional package), and thougt I'd try converting the code to use units. Then I thought, I should put it online for all to see - an a moment of perhaps ill-advised grandeur - and so here we are. Unfortunately, during the development of this notebook, I found that I can't actually build the units module (since I am using the default ghc version provided by Ubuntu 14.10, which is version 7.6.3), so I ended up using a variant of the dimensional package.

I had best point out that the following is not going to present a robust, well-thought out, API for a Cosmology library!

What is this document?

This is an IHaskell notebook, which uses the notebook features of IPython to support an interactive Haskell environment. Now, Haskell compilers tend to provide an interactive environment - commonly known as a repl - but the advantage of IHaskell is the HTML support and easy display of non-textual items (so, similar to why people like IPython notebooks when there's the ipython command-line environment).

Since this is an interactive environment, there are several differences to how code would be written and run in compiled code, but we can ignore these for now.

How do you install and setup the code?

This section can be skipped if you are not interested in trying the code out.

For this analysis, I am using the default set of packages on my Ubuntu 14.10 machine: ghc version 7.6.3, the Haskell compiler, and cabal-install (at version 1.20.0), which is used for package management (e.g. is is something like pip). Later versions should (hopefully) work, but earlier versions may not (the cabal sandbox command needs a cabal-install version of at least 1.18 and I don't know how well ghc version 7.4 or earlier are going to work).

With these installed, and having moved to a new directory, I set up a "sandbox" environment in which to install the Haskell packages (to avoid conflicting packages and to make it easy to remove or update changes for just this project), and enter

% cabal update
% cabal sandbox init
% cabal install integration chart-diagrams ihaskell ihaskell-blaze --dry-run
Resolving dependencies...
In order, the following would be installed (use -v for more details):
Boolean-0.2.3
NumInstances-1.4
...
% cabal install integration chart-diagrams ihaskell ihaskell-blaze
Resolving dependencies...
Notice: installing into a sandbox located at
/home/dburke/posts/cosmo/.cabal-sandbox
Downloading Boolean-0.2.3...
Downloading NumInstances-1.4...
Downloading OneTuple-0.2.1...
...
... and wait quite a while
...

This will create (if it doesn't already) the directory ~/.cabal/ as well as .cabal-sandbox/ in the current directory.

At this point you should be able to say

% cabal repl
GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> import Numeric.Integration.TanhSinh
Prelude Numeric.Integration.TanhSinh> :quit
Leaving GHCi.

which checks that things are set up correctly.

We now need to run IHaskell, which will then set up its own version of IPython (unless it can find one it is able to use), and store it in ~/.ihaskell/.

% mkdir notebooks
% cabal exec IHaskell -- notebook --serve=notebooks/
Did not detect IHaskell-installed or system IPython.
IHaskell will now proceed to install IPython (locally for itself).
Installing IPython in IHaskell's virtualenv in 10 seconds. Ctrl-C to cancel.
...
... this will install into ~/.ihaskell
...
Successfully installed ipython-2.4.1
Creating IPython profile.
...
... normal ipython notebook output
...
2015-02-09 19:28:24.287 [NotebookApp] The IPython Notebook is running at: http://localhost:8778/
2015-02-09 19:28:24.287 [NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).

At this point you should be able to go the URL where the server is running and start a notebook to follow along. If you just want to try a few things out, then the Try Haskell! and FP Complete sites provide on-line environments for trying out Haskell.

For reference, the versions of the major packages used in this notebook are (dimensional-tf is added in later):

cabal exec ghc-pkg -- list | egrep -i 'ihaskell|integration|dimensional|chart' 
    Chart-1.3.3
    Chart-diagrams-1.3.3
    dimensional-tf-0.3.0.1
    ihaskell-0.4.3.0
    ihaskell-blaze-0.1.0.0
    integration-0.2.0.1

Setting things up

Here I just load in a few modules that will be used later, for displaying a graph. In Haskell, the form import a loads all the symbols defined for export from the module a; that is, it is like Python's from a import *. There are ways to import just one or more symbols, or to load in a module using a qualified name, both of which are used later.

Normally we would just install the ihaskell-charts package and not have to bother with this, but version 0.1.0.0 of this package does not build with version 1.3 of Chart. There is a fix for this on the GitHub version of ihaskell-charts but it's also possible to write it directly by converting the output of Chart into a form that the ihaskell-blaze package knows how to display.

What is the distance between two points?

I want to calculate the angular-diameter distance to a source, so that I can find out what the projected separation between two points is when all I know is a redshift and an angle. The parameters we are interested in are the redshift of the source, $z$, the matter-density ($\Omega_m$), the vacuum-density ($\Omega_\lambda$), and Hubble's constant ($H_0$).

The angular-diameter distance, $d_A$, is

$$d_A (z; \Omega_m, \Omega_\lambda) = \frac{c}{H_0} \frac{d_c(z; \Omega_m, \Omega_\lambda)}{1+z}$$

where $d_c$ is the comoving distance to the source. For simplicity, I am going to assume that we are only interested in flat cosmologies; that is, where $\Omega_m + \Omega_\lambda = 1$ (i.e. $\Omega_k = 0$), which leaves me to calculate:

$$d_A (z; \Omega_m) = \frac{c}{H_0} \frac{\int_0^z f(z; \Omega_m) dz}{1+z}$$

where

$$f (z; \Omega_m) = 1 / \sqrt{ (1+z)^2 (1 + \Omega_m z) - (2+z) (1-\Omega_m) z }$$

So, I start by defining the $f$ function, which has arguments of $\Omega_m$ (om) and redshift (z):

There are several things to note here:

• The first two lines are comments.

• The third line gives the signature of the function: the label before :: is the name of the function and the types of the arguments are separated by the arrows (->), with the last type being the value calculated by the function. So, f takes two Double values and returns a Double.

  This signature line is not required, since the Haskell compiler can determine the types. However the types it infers a more general than the ones I gave (it has worked out that both Float or Double could be used). I chose to force Double since the integration routine I use below works on Double types and it simplifies some of the discussion below, such as when asking for the type of the g function.

• The function arguments on line four are separated by spaces rather than brackets and commas.

• The definition of the function (lines four to siz) uses the let xxx in yyy form, which defines a set of local symbols (in this case ol and t) which are then used to calculate a value.

• Function application does not use brackets, so the denominator of the fraction is just sqrt t. However, precedence rules means that brackets may be needed to clarify what is an argument. For instance, if I had not used the temporary symbol t then I would have had to write 1 / sqrt ((1 + z)^2 * (1 + om*z) - (2 + z) * ol * z).

The above is similar to the Python code:

def f(om,z):
    ol = 1 - om
    t = (1 + z)**2 * (1 + om*z) - (2 + z) * ol * z
    return 1 / math.sqrt(t)

I now want to check how $f$ varies with redshift for a given $\Omega_m$ value (in this case I want to use a value of 0.3, since that is close to the currently-preferred cosmological model). I can do this by taking advantage of partial application to easily create a function that calls f with the first argument fixed to 0.3:

The Python version would be something like

def g(z):
    return f(0.3, z)

or

g = lambda z: f(0.3, z)

Since I am often going to be interested in how things vary with redshift, I am going to make this parameter the last one, so that it makes it easy to partially apply the functions I write (as in the case of making g a specialized version of f).

The :type command - which is part of the interactive Haskell environment rather than Haskell itself - reports the type of a symbol: in this case it shows us that g is a function that takes a Double and returns a Double (so it has one less "Double ->" term than f).

I am going to gloss over the fact that Haskell functions only ever accept a single argument, using curried functions to implement what appear to be multi-argument functions. It is an important point to understand if you are going to be writing Haskell, but I don't want to derail the discussion too much.

Getting back to the code, I can evaluate g for $z=0$ and then $z=1.2$ (taking advantage of the automatic-display capabilities of the IHaskell notebook; in an actual Haskell program we would have to say something like print (g 0) to display the value):

I want to evaluate this function for a number of different redshifts, so I want to automate this process, which leads to lists and the map function.

In Haskell, lists of objects are represented by comma-separated values enclosed by [] brackets - e.g. [1.2, 3.4, 9.8] - and have a type of [a], where a is the type of the list element. The map function takes a function which accepts one argument, as well as a list of arguments, and returns a list of values created by applying the function to each argument. That is, it has a type of:

For this discussion we can ignore the forall a b part of the type.

To be general, the function supplied to map can have different types for its input and output lists, (so a and b above) but here we will use g which means that the input and output lists have a type of [Double]:

which means that the following evaluates g with z=0, z=0.4, and z=3.2:

I want to look at g evaluated for a range of redshits between 0 and 10, so let's create the list of redshifts (a common scheme when naming variables in Haskell is to add a s for a list of values, hence the use of zs here) and evaluate g on each element:

The form [a, a+dx .. b] is similar to NumPy's numpy.arange(a, b+dx, dx), so this is similar to the Python/NumPy code

zs = numpy.arange(0, 10.1, 0.1)
# You could use Python's map
gs = map(g, zs)
# or a list compreshension
gs = [g(z) for z in zs]

Note that I am ignoring the difference between Python lists and NumPy arrays here.

I did not need to add ::Double to 0 when creating zs, but did so just to keep the types "concrete". If I had said

zs = [0, 0.1 .. 10]

then gs would still be a list of Double values, but the type of zs would be

forall t. (Enum t, Fractional t) => [t]

and I don't really want to try and explain Haskell type classes (the names to the left of the =>) here.

We can finally take advantage of the display code I wrote at the start of the notebook, and use the routines from the Graphics.Rendering.Chart.Easy module of the Chart package to display gs versus zs:

This command doesn't look like anything I've shown so far, and I don't really want to explain it too much, but the toRenderable function takes a list of actions, which describes the plot, and converts it a value with a Renderable type, defined in the Chart package, which is itself then converted into SVG and automatically displayed by the notebook, due to the code I wrote way back at the start.

The list of actions is created using do notation, which is a way of representing a chain of actions - in this case things like "set the X-axis label to 'Redshift'" and "plot up this list of (x,y) points" - in Haskell. This is very terse and it's best if you just let your eyes skip over the code and focus on the plot instead.

Integrating $f$

To calculate the angular-diameter distance I need to integrate f. The "Why functional programming matters" (link to PDF) article by John Hughes provides a nice implementation that highlights some of the ways that lazy evaluation can be used to simplify code. However, it's easier to use a pre-canned solution, and in this case I have chosen to use the integration package:

There are several ways to integrate up a function, and the results can be bounded to a relative or absolute limit. The function g is "well behaved", so a simple integration scheme is likely to be sufficient. The runs below - where I have approximated $\int_0^2 g(z) dz$, show that both Simpson's and the trapezoidal methods agree, so I shall use trap (the absolute limit of 1.0e-6 is excessive but the run times are not prohibitive here):

The result of absolute is a Haskell record, but all we need worry about now is that the value of the integrated function can be retrieved from it by using result, as shown below:

If you are wondering what just happened: the simpson and trap routines take a function of one parameter (the function to integrate, so g here) and a range over which to integrate ($z=0$ to $z=2$ here), and return a list of approximations (the [Result] return type) which (hopefully) converge on the answer. The absolute routine takes a limit value and a list of results, returning the first one whose error estimate is smaller than the given limit.

We can look at these return values, using the take 3 function that returns the first three elements of a list, to see that the result has converged quickly:

Getting back to the task at hand, I can define daH as a function that accepts $\Omega_m$ and $z$ and returns the angular-diameter distance, in units of the Hubble length, by saying:

The equivalent Python would be something like

def daH(om,z):
    # I am assuming here that the integrate and trap methods are
    # defined somewhere else.
    fs = integrate(lambda z: f(om,z), 0, z, method=trap, abstol=1.0e-6)
    return fs / (1+z)

Although not given explicitly, the compiler can infer that the two input arguments, and the result, have a type of Double:

As I want to plot up the angular-diameter distance as a function of redshift for several different cosmologies, I define a helper function that, given an $\Omega_m$ value, returns a list of $(z, dA(z))$ points, which is in the form needed by the line command used earlier.

The Python equivalent would be:

def calcDAH(om):
    zs = np.arange(0, 10.1, 0.1)
    return [(z, daH(om,z)) for z in zs]

This can then be used to display the results for several cosmologies:

The plot shows the non-monotonic nature of the angular-diameter distance.

Converting to a physical distance

To get a value with physical units, we multiply daH by c/$H_0$, which, if the speed of light is in km/s and $H_0$ in km/s/Mpc, will give a value in Megaparsecs:

For variety I chose to use the form xxx where yyy rather than let yyy in xxx, as used in earlier examples.

This routine can then be used to calculate angular-diameter distances for a range of redshifts:

As a sanity check, I used Ned Wright's CosmoCalc calculator and recorded the distances for several redshifts. These are stored in the nedWrightDA list, and then I calculate the ratio of the distance I calculate to those from CosmoCalc (the rel list). As can be seen, the values are all close to 1.0.

The Python equivalent for calculating rel would be something like (where I have decided to use shorter variable names than above):

da = [da(0.3,70,z) for z in [0.5, 1, 1.2, 2]]
nw = [1259.0, 1651.8, 1710.5, 1726.3]
rel = np.asarray(da) / np.asarray(nw)

I can now repeat the previous plot, this time with physical units:

Calculating the separation between two points

To get the linear distance between two points at the same redshift, separated by an angle of theta, we can use the small-angle approximation: convert the angle to radians and then multiply it by the angular-diameter distance. Astronomers use all kinds of funny units for angles; in this case I am assuming the input angle has units of arcminutes. As there are 60 arcminutes to a degree, the conversion to radians is just $\pi / (180*60)$.

For a redshift of 2, with a closed cosmology and $\Omega_m = 0.3$, the CosmoCalc calculator calculate a scale of 8.370 kiloparsecs per arcsec. How close do I get (given that one arcsec is 1/60 of an arcminute and I intentionally made adist return values in kpc):

So, not bad agreement. As a reminder, the code I had to write to get this (stripping out all the non-essential bits, including niceties like type signatures and comments, from above) was:

f om z = let ol = 1 - om
         in 1 / sqrt( (1+z)^2 * (1 + om*z) - (2+z) * ol * z )

daH om z = let fs = result (absolute 1.0e-6 (trap (f om) 0 z))
           in fs / (1+z)

da om h0 z = daH om z * c / h0
  where
    c = 299792.458

adist om h0 z angle = 1000 * d * a
    where
      a = pi * angle / (180 * 60)
      d = da om h0 z

If I wanted to make this code usable I would spend some time thinking about whether it is worth defining types especially for the matter density, Hubble's constant, or redshift values, to clarify routines like adist which take four Double values and it is easy to mix them up - e.g. swapping om and h0 - leading to incorrect results. However, that's a discussion for another day.

Adding units and quantities

The above calculation is fine, but I'd like to explicitly include the units in the calculation, so that you know the answer is in Mpc (or some other unit). There are several Haskell packages that support this; I have previously used the dimensional package and there is also unittyped and quantities, but today I want to try the units package. As I have not tried out the support for quantities and units in astropy I do not provide Python equivalents for the rest of this notebook.

Unfortunately, using ghc version 7.6.3 means that only the first version (1.0.0) of units can be used, which is a problem, since it doesn't build! So I decided to try out the dimensional-tf package, since it a different approach to the dimensional package, which I have used. The difference between the two is not really relevant here; we can just look at is as being one way to model quantities and units in a physical calculation in Haskell. I hope to have time to repeat this with a more-recent version of ghc so that I can try out units.

To install the necessary package we need to use cabal again:

cabal install dimensional-tf --dry-run
... check that no problems are reported
cabal install dimensional-tf
... this should be relatively quick as there's not that many
... dependencies that need to be built

The following statement is similar to Python's import foo.bar.baz as bob statement; symbols defined by the module must be preceeded by the quaifier P. The reason for doing this is that this module provides versions of common mathematical operations - such as multiplication - which would conflict with the default versions. It will make it clear what version I am using, but is visually distracting, as you will soon see!

I start by defining the speed of light, c, in meters per second (you can use P.meter or P.metre here):

The inferred type for this is confusing:

This can be fixed by giving an explicit type, as shown below (it's not actually necessary to do so, but I do so because I can):

The type is now more readable, but in reality this is just a synonym for the original type (except that the Fractional constraint has been replaced by the use of an explicit type Double, which is a member of the Fractional type class). Although not relevant here - as I'm treating the module as something of a black box - the dimensions of the value are encoded here using Peano numbers, where Z indicates 0, S a is one more than a (so S Z is 1 and S (S (S Z)) is 3), and N a is used to negate a. The Dim statement from the original type of c can therefore be read as Dim 1 0 -1 0 0 0 0, so this suggests that the first element refers to length and the third refers to time. I believe the reason for using Peano numbers here is because they are inductively defined (the base case is 0 and the inductive step is add one), which means that the type checker can match up things as needed. One thing to note, if you've read this far into the paragraph, is that this information is only relevant when the code is compiled. This means that you only "pay" for the checking when you build the code (which can, unfortunately, take some time for particularly complex cases) rather than when you run it.

More information on the API of the dimensional-tf package can be found in the source code to this module, as it uses a literate programming style which means that the comments do not get displayed in the standard module documentation. The main thing to note just now is that there are types for quantities - such as the speed of light in meters per second - and for units - such as second. These types are labelled Quantity or Unit and contain the relevant dimension information (the Dim type seen above) and the type of the numerical value (e.g. Double). Synonyms are used to make these more readable, such as Velocity meaning Quantity DVelocity and DVelocity being Dim (S Z) Z (N (S Z)) Z Z Z Z, which can sometimes be a bit confusing when you are trying to work out how everything fits together.

The symbol c now retains both the quantity and the units, as displaying it shows:

The quantity stored in c can be extracted, converting to a given unit, using the /~ operator, as shown below (note that this is one point where the use of the P prefix is visually distracting):

Using it in a calculation is also somewhat unsatisfting, since you need to use the mathematical operators from the module - leading to visual clutter if you use the approach I have taken here - and the need to use constants such as P._2 to represent the value 2:

Alternatively, I can "convert" a value into a dimensionless number by using the form value *~ one (which is needed when there is no pre-defined constant):

Here I define a symbol that represents one arcminute. The use of 1::Double is just to make sure that this is a Double value, rather than a more general one, in a similar manner to how c was defined.

One of the reasons for using a system which also encodes units is to make it an error for combining incompatible values; in this case trying to add together the speed of light and an angle is an error. Admittedly, a rather confusing one if you're not used to the Haskell type system.

I guess that the "native" value for angles is radians, so let's check this:

which is one arcminute in radians, since:

I can also check that the numerical values are equal directly, by using /~ radian to extract then numeric value from arcmin:

If I had not "converted" arcmin from a quantity to a standard value, using /~ radian, then I would have come across another rather frightening error message:

I want to be able to handle lengths which contain parsecs, so I need to create a unit for this, using the prefix function:

With this, I can now create distances in units of mega parsecs:

and even define a unit for the Hubble constant:

I included the explicit type to make things a bit more readable - the inferred value is Dimensional DUnit (Dim Z Z (N (S Z)) Z Z Z Z) Double - and also to ensure that the equation I used is sensible (i.e. that the units are correct). As an example, if I had missed out the "per second" part then I would have got the following error (I promise that you can, with enough experience, work out what's going on from these error messages):

When the hubbleConstant is applied to a value, the result has a type of Quantity DFrequency Double, as shown below:

Since I will want to use this type a few times below, I define an alias for it, using the type command. After this, I can use HConstant to simplify signatures of functions that take a Hubble constant as a parameter; I also add in a Length alias, since this will also come in useful.

With these definitions I should now be able to replicate the angular-diameter calculation, but this time tracking the types as well. As a reminder, I want:

f om z = let ol = 1 - om
         in 1 / sqrt( (1+z)^2 * (1 + om*z) - (2+z) * ol * z )

daH om z = let fs = result (absolute 1.0e-6 (trap (f om) 0 z))
           in fs / (1+z)

da om h0 z = daH om z * c / h0
  where
    c = 299792.458

adist om h0 z angle = 1000 * d * a
    where
      a = pi * angle / (180 * 60)
      d = da om h0 z

Since f and daH are dimensionless, I'll just re-use them and concentrate on da and adist.

There are four main points in the conversion of da:

1. I added a signature to ensure that the Hubble constant has the required units. This trades off generic behavior (accepting any quantity) against some measure of type safety (in the sense that I want to make sure the second argument has the units of Hubble's constant). The results below would not change if I did not give the signature.

2. I have not had to convert c from m/s to km/s (or, equivalently, explictly convert the Hubble constant to account for the use of both km and Mpc).

3. The value returned by daH is converted to a dimensionless quantity by "multiplying" it by one.

4. The result does not look too different from the original form.

The conversion for adist is also simple.

Since I did not give a type signature, the inferred version does not require that the angle be dimensionless (shown by the fact that d', which represents the dimensions of the value, is listed as forall rather than being an explicit value):

I can fix this by explicitly specifying that the fourth argument is an angle by saying

The difference in type signatures can be seen if I give a non-angle value for the last argument: the adist2 form returns a value whereas the adist3 version raises an error:

With this, I can repeat the earlier calculation, which gave

adist 0.3 70 2 (1/60) = 8.370893333112804

Oops: I want the answer in kpc:

It is easy to change units, such as to use an angle in arcminutes and to convert the answer to Mpc:

Finishing it all off: luminosities

The luminosity of a source is equal to $4 \pi d_l^2 f_x$, where $d_l$ is the distance to the source and $f_x$ its flux (this assumes a bolometric flux, since it ignores the K correction).

For a source at a cosmological distance, the distance used is the luminosity distance - which is why I used the subscript $l$ - and it is defined as

$$d_l = (1+z) d_c$$

Trying it out, I get (using the same Cosmology as previously) a luminosity distance to an object at $z=2$ of:

which, in Astronomer friendly units, is:

The CosmoCalc page returns 15537.0 Mpc or 50.675 Gly. Now, can I easily convert the answer above to light years?

For this, I need to import the year value from the "non SI" module of dimensional-tf

and use it - together with the definition of c above, to calculate the distance light travels in a year. I am not happy with the following, as I calculate a value in meters, remove the meters, then make it into a unit of meters, but I couldn't see how else to convert a Quantity - which is what c * year is - into a Unit.

With this, I can convert the distance into light years to compare to the cosmoCalc value:

Finally it's time to create a function that converts a flux to a luminosity:

As an X-ray astronomer I'm used to working in units of ergs (please don't ask why), so I create a few units built on this: one for flux and one for luminosity.

With these I can finally calculate the luminosity of a source ($z=2$, $\Omega_m=0.3$, $\Omega_\lambda=0.7$, $H_0 = 70\ {\rm km/s/Mpc}$) which has a flux of $2 \times 10^{-13}\ {\rm erg/cm^{2}/s}$.

This value is

which can be converted to several units; such as ${\rm Watts}$

which is - unsurprisingly - the same numerical value, or $\rm{erg / cm^2 / s}$, which has a numerical value $10^7$ times this:

Don't forget that this would need some form of K-correction, unless you have a bolometric flux measurement.

Just one more thing ...

Whilst I have your attention, how about calculating the critical density of the Universe, which is defined as:

$$\rho_{\rm crit} = \frac{3 H^2}{8 \pi G}$$

For this, I need a value for the Gravitational constant, where the meter ^ pos3 and second ^ pos2 terms represent $m^3$ and $s^2$ respectively.

With this, I can write out the equation to calculate the critical density:

Applying this to $H_0 = 70\ {\rm km/s/Mpc}$ gives:

which I can convert to other units, such as metric tons per cubed Astronomical Unit:

The use of the P. prefix is definitely distracting here. The way I've used the dimensional package in the past is to have most of the code in a module, and in that module I have imported the module directly. This means that the code can be written in the more-natural form

criticalDensity h = _3 * h ^ pos2 / (_8 * pi * bigG)

The downside to this is that normal arithmetic becomes more verbose.

The end

There you go; I hope you enjoyed it. If you have any questions, then please use the GitHub issues page or contact me on Twitter at https://twitter.com/doug_burke.